The increase in packet traffic and parallel increase in bandwidth consumption that results from normal network activity such as generating routing tables and system updates is easily handled by local-area networks (LANs); these types of networks have ample bandwidth to handle the extra traffic. The same is not true for networks that make use of wide-area network (WAN) services such as Integrated Services Digital Network (ISDN). While on-demand routing software makes efficient use of WAN services, the additional traffic generated by normal network activity can result in excessive activation and use of the line and defeat the cost effectiveness. Cisco Systems recognizes the challenges facing network managers and designers who implement Novell NetWare in dial-on-demand (DDR) environments. Cisco Systems has pioneered many solutions to these problems and offers tools from the Cisco Internetwork Operating System (Cisco IOS(TM)) software that have been designed to ease these challenges. This paper looks at running Novell NetWare in a dialup environment and describes NetWare-specific issues that can cause dialup links to stay connected, along with Cisco Systems' solutions to these issues.
When running Novell NetWare in a WAN that is also using DDR, network managers must consider several issues.
The first of these are routing issues that result from routing updates. Novell NetWare frequently broadcasts routing and service updates, which might keep the DDR lines active. When expensive WAN services such as ISDN are used for the DDR line, this constant use of the line can be prohibitively expensive.
Other traffic can also trigger the DDR link unnecessarily and present connectivity issues. Some NetWare operating system components regularly transmit packets to report inactive connections, to check that both ends of a connection are active, and to protect licensed copies of NetWare from being illegally copied. Novell is also introducing a new management framework that regularly transmits packets between management stations to stay synchronized.
Cisco Systems understands the ramifications of each of these potential problem areas. This paper describes solutions to each, and addresses which solution might be best suited for a particular environment.
The Routing Information Protocol (RIP) and the Service Advertisement Protocol (SAP) are two key components of Novell NetWare and its Internet Packet Exchange (IPX) protocol suite. By default, Novell NetWare versions 3.x and 4.x broadcast RIP and SAP updates at 60-second intervals. NetWare uses these broadcasts to collect information for the routing and service tables that it uses to communicate. However, each broadcast can open a DDR line, thereby keeping the lines in a constantly up state. Additionally, these broadcasts can significantly increase line bandwidth requirements, as the following figures and examples illustrate.
Figure 1 illustrates the structure of a RIP Synchronous Data-Link Control (SDLC) packet:
Figure 1. RIP SDLC Packet Format
Each fully loaded RIP serial packet contains 40 bytes of fixed header and SDLC identification information and up to 50 eight-byte network numbers. (The last packet in a string might contain less than 50 network numbers if the total number is not evenly divisible by 50.)
A full RIP packet with 50 network numbers contains 40 bytes of header and identification, plus 400 (50*8) bytes of data, for a total of 440 bytes. Converting these bytes to bits and multiplying by the actual number of packets in a network makes it easy to see how these packets can significantly increase bandwidth consumption in the network.
The following examples illustrate the increase in bandwidth consumption for 50, 200, and 1000 routes, based on one full RIP update every 60 seconds.
Example 1: 50 RIP Routes (1 full RIP packet)
| Convert to bits: |
440*8 = 3520
|
| Bits per second (bps): |
3520/60 = 59 bps
|
Example 2: 200 RIP Routes (4 full RIP packets)
| 59*4 = 236 bps |
Example 3: 1000 RIP ROUTES (20 FULL RIP packets)
| 589*20 = 1180 bps |
Figure 2 illustrates the structure of a SAP SDLC packet:
Figure 2. SAP SDLC Packet Format
A SAP SDLC packet can contain up to seven 64-byte SAP entries, along with the bytes needed for header information. A full SAP packet with seven SAP entries contains 40 bytes of header and identification data plus 448 (64*7) bytes of data, for a total of 488 bytes. As with the RIP packets, SAP packets are filled to capacity, and networks with services not divisible by seven will have partially filled packets.
The following examples convert the number of bytes in a SAP packet to bits and illustrate the increased bandwidth consumption for 50, 200, and 1000 SAP services in a network, then illustrate the amount of time it takes to transmit the packets over high-speed lines.
Example 1: 50 SAP Services
| 50 SAP packets = 7 full packets and 1 packet with 6 SAPs 7 full packets: |
7*488 = 3416
|
| Plus 1 packet with 1 SAP: |
40 + (1*49) = 89
|
| Total bytes: |
3505
|
| Convert to bits: |
3505*8 = 28,040
|
| Total bits per second (bps): |
28,040/60= 467 bps
|
Example 2: 200 SAP Services
| 200 SAP packets = 28 full packets and 1 packet with 4 SAPs |
| 28 full packets: |
28*488 = 13,664
|
| Plus 1 packet with 4 SAPs: |
40 + (4*49) = 233
|
| Total bytes: |
13,900
|
| Convert to bits: |
13,900*8 = 111,200
|
| Total bits per second: |
111,200/60= 1853 bps
|
Example 3: 1000 SAP Services
| 1000 SAP packets = 142 full packets and 1 packet with 6 SAPs |
| 142 full packets: |
142*488 = 69,296
|
| Plus 1 packet with 6 SAPs: |
40 + (6*49) = 334
|
| Total bytes: |
69,630
|
| Convert to bits: |
69,630*8 = 557,040
|
| Total bits per second: |
557,040/60 = 9284 bps
|
Since RIP and SAP updates occur once each minute, another way to represent the impact on a wide-area circuit is to look at the amount of time spent sending these updates each minute. The following examples calculate the time required to transmit 1000 SAP services within a 60-second interval over 19.2 kilobits per second (kbps), 56 kbps, and 64 kbps line speeds:
Example 4: 1000 SAPs over 19.2-kbps Line
557,040/19.2 kbps = 29 seconds
|
This example illustrates that transmitting 1000 SAPs takes roughly a half a minute using a 19.2-kbps line speed.
Example 5: 1000 SAPs over 56-kbps Line
557,040/56 kbps = 9.9 seconds
|
This example illustrates that transmitting 1000 SAPs takes roughly 10 seconds using a 56-kbps line speed.
Example 6: 1000 SAPs over 64-kbps Line
557,040/64 kbps = 8.7 seconds
|
This final example illustrates that transmitting 1000 SAPs takes over 8 seconds using a 64-kbps line speed.
These examples illustrate the demand on bandwidth placed on lines by the RIP and SAP packets, both by number of packets added to the traffic flow and by the additional time it takes to transmit them. In Example 4, where 1000 SAPs are transmitted over a 19.2-kbps line, almost half the circuit is dedicated to transmitting SAP information.
However you look at it, unless action is taken to mitigate the behavior of these protocols, the cost of using Novell IPX over the DDR link can become prohibitive.
Cisco offers the following as possible solutions to reduce or eliminate the routing updates that can trigger the DDR link:
Each solution is described in a following section.
Routers and servers running Novell IPX RIP use a broadcast message to communicate route availability. By default, this broadcast occurs every 60 seconds. Increasing the interval between RIP broadcast messages is one way to preserve WAN bandwidth and reduce DDR link usage.
The Cisco IOS software includes a feature that varies the interval between broadcasts. Increasing this interval at each end of a DDR link correspondingly reduces line usage. Use the Cisco IOS ipx update-time software command to implement this feature. Be sure the IPX updateinterval is increased the same amount on each side of the DDR link.
This solution can have a negative impact on network convergence however, because it increases the amount of time it takes for a change in network topology to be learned by all the routers in the network. Slow convergence can cause problems such as routing loops.
Similar in nature to RIP broadcasts, SAP updates are broadcast by each server and router. NetWare uses SAP updates to provide information on known services throughout the internetwork. By default, each server and router broadcasts a complete list of known services every 60 seconds.
The Cisco IOS software provides a feature that changes the amount of time between SAP updates. Be aware that increasing the interval between SAP updates also increases the time it takes for the network to learn changes in the availability of services, and this can have a negative impact on how quickly new services are advertised throughout the network. Use the ipx sap-interval command to implement this feature.
Be sure the SAP interval is increased the same amount on each side of the DDR link. Failure to increase the interval to uniform values can result in services being dropped from the service tables and becoming unavailable.
One way to keep RIP and SAP broadcast messages from tying up DDR links is to use static routing tables. Doing this removes the need for RIP broadcasts and SAP updates, which function to create dynamic routing tables. The Cisco IOS software provides the capability to define routes and services in static routing tables. This is done using the ipx route and ipx sap commands.
While this solution can be effective for small networks that are not subject to significant change, there are drawbacks. Manual entry of all permissible routes and services is a labor-intensive task, and the maintenance of these tables requires considerable administrative overhead. Additionally, static RIP and SAP routing tables often do not accurately reflect the true state of all available networks and services. For example, any statically defined network that becomes unreachable continues to be advertised as being reachable until the routing table is manually updated.
Snapshot routing is a time-triggered routing update facility that enables remote server routers to learn dynamic routing and service information from a central client router during an active period (T1 in Figure 3).
This "snapshot" of the routing and service information is then stored for a user-defined quiet period (T2 in Figure 3) until the next active period. If no routing updates are exchanged during the next active period, a user-configurable retry period (T3 in Figure 3) is started to ensure that a full quiet period does not pass before an attempt is made to exchange routing information again. For example, the T3 time might be started because a DDR phone number or interface is unavailable.
Snapshot routing can be used with these routing protocols:
Snapshot routing is useful in ISDN environments where it can provide a solution to the problem of implementing and maintaining static routes in large DDR networks. However, if there are crucial locations that must always be in the routing table, it might be best to configure them statically to make certain they are always available. If the desired location is not statically defined and is temporarily down during the snapshot active period, the route to this destination is lost for one complete quiet period or longer.
Enable snapshot routing by using the snapshot client command on one side of the DDR link and the snapshot server command on the other side. You will need to supply parameters for the active, quiet, and retry periods.
Figure 3. Snapshot Routing
While snapshot routing uses a time schedule to trigger the active period during which it collects routing updates, another approach known as event-triggered routing is based on network status. In this case, RIP and SAP updates are sent over the WAN link only when there is a change in routes or services.
The Cisco Access Business Unit uses the event-triggered routing solution in its LAN2LAN(TM) routers. While this technology is not currently offered in the Cisco IOS software, it has been adapted by several niche vendors. For this reason, it is important to understand how it works and how it compares with snapshot routing.
In event-triggered routing, the DDR link is opened for the exchange of RIP and SAP information each time a route or service in the network changes state. Snapshot routing allows users control over the time the client is active, while event-triggered routing does not allow this control. Although event-triggered routing reflects network changes more quickly than snapshot routing, an unstable event-triggered routing network can frequently trigger a call to be placed. Event-triggered routing is most cost effective and best suited to network environments that are not prone to change.
Traditionally, static routes are implemented so that they always take precedence over any dynamically learned routes to the same destination network. A floating static route is statically configured but can be overridden by dynamically learned routing information. Thus, a floating static route can be used to create a path of last resort that is only used when no dynamic information is available.
Floating static routes make it possible to design and build very flexible and robust routing topologies. One important application of floating static routes is to provide backup routes in topologies that use DDR. Figure 4 illustrates the configuration for a backup route.
Figure 4. Novell IPX Backup Route
In this scenario, the preferred path from Network 1 to Network 2 is the leased line that exists between Routers A and B. However, there is an alternative path from Router A through Router C and on to Router B through a dial-up service using ISDN.
When a floating static route is configured in Router A, any failures on the leased line between Routers A and B cause Router A to forward traffic from Network 1 to Router C. Traffic received by Router C, which also maintains a floating static route, triggers dialing and sets up a circuit, and the traffic is then forwarded to Router B and Network 2.
Once the leased line from Router A to Router B is restored, dynamic routing information overrides the floating static routes, and traffic again uses the preferred leased-line path.
The Cisco IOS software provides the floating static route capability; it is an option of the ipx route command.
Novell NetWare is a network operating system and as such, generates periodic updates to maintain information on network operation and efficiency. Similar in function to the packets transmitted by a router to update routing information, these periodic updates also trigger the circuit-switched WAN services and make their use costly.
One such update is generated by the NetWare IPX Watchdog protocol, which monitors the connection status of NetWare clients and transmits reports when a connection fails to respond.
Networks that require guaranteed sequence and delivery of packets use the Novell Sequenced Packet eXchange (SPX) protocol. This protocol transmits keepalive messages between the client and server ends of a connection.
The NetWare operating system has a built-in copy protection scheme that transmits a packet containing a unique serialization number between servers to protect licensed copies of NetWare from being improperly used on multiple serves. You can perform any of these tasks to reduce network costs:
Additionally, NetWare version 4.1 includes the NetWare Directory Services (NDS), a new management framework that relies on regular communications between management stations to stay synchronized. Some of the more advanced issues involved with using NDS are described in Novell, Inc. application notes. This section also briefly summarizes these notes and how to obtain them from Novell, Inc.
Within the Novell NetWare operating system, the Watchdog protocol, which is one of the NetWare Core Protocols (NCPs), periodically queries for inactive workstation connections and transmits updates to the system when a connection fails to respond appropriately. The system closes connections that Watchdog reports as unavailable.
These update packets increase the amount of time a WAN circuit-switched service is in use, thereby also increasing the cost of the service. One way to decrease the amount of time the circuit is switched on is to decrease the number of Watchdog update packets. The Watchdog protocol has three parameters that are set at the file server prompt:
| SET DELAY BEFORE FIRST WATCHDOG PACKET = n |
|---|
| SET DELAY BETWEEN WATCHDOG PACKETS = n |
| SET NUMBER OF WATCHDOG PACKETS = n |
The default delay period for transmissions between a workstation and server is four minutes and 56.6 seconds, after which the Watchdog sends the update packet. The default delay between Watchdog packets is 59.3 seconds, but can be changed to between 15.7 seconds and 20 minutes 52.3 seconds. If the workstation does not answer within the defined interval, by default Watchdog transmits ten packets, but this can be changed to any number between five and 100.
In place of reconfiguring parameters within NetWare software, the Cisco IOS software provides a feature that allows the router to respond to a server's Watchdog requests on behalf of a remote client. This process is called NCP or IPX spoofing. Benefits of IPX spoofing include the following:
In the example configuration illustrated in Figure 5, only Router A needs to spoof IPX Watchdog packets, because IPX Watchdog packets are generated by the NetWare server.
In some cases when using IPX spoofing, NetWare servers can believe that a session is still active when it is not. When the number of IPX or SPX sessions are limited, this can cause connectivity problems by denying logins to legitimate users. NetWare includes an auto logoff feature that should be used to minimize this possibility. Use the ipx watchdog spoof command to implement IPX spoofing; no arguments are required.
Figure 5. IPX Watchdog Spoofing
Application programs use the SPX protocol rather than IPX when they require guaranteed, sequenced delivery of packets. Examples of these types of programs include console and printer applications such as Novell's Remote Console (RCONSOLE) and Remote Printer (RPRINTER), gateway applications such as NetWare for Systems Application Architecture (SAA), and some remote database applications.
When an SPX connection is established, both ends of the connection exchange keepalive requests to track periods when no data is transmitted. By default, these keepalives are exchanged every three seconds for NetWare 3.x and every six seconds for NetWare 4.x on the server. Timers on the server cannot be changed; however, keepalive timers can be changed on the client side by editing the NET.CFG file and modifying the SPX Verify Timeout and SPX Abort Timeout parameters.
The default value for the SPX Abort Timeout parameter is 540 ticks, and for the SPX Verify Timeout parameter, 54 ticks. One tick equals 1/18th of a second. Values for these parameters can go up to 65,000 ticks, or approximately one keepalive every hour.
Another way to prevent SPX keepalive exchanges, which can consume significant bandwidth and run up costs on pay-per-packet WAN links, is to enable SPX spoofing. This is a Cisco IOS software feature that enables the Cisco router, rather than the SPX application, to respond to the keepalive packets. SPX spoofing keeps the packets off the WAN link yet maintains the NetWare connection. The configuration in Figure 6 illustrates that Router A has an Ethernet connection to Network 100 and an Integrated Services Digital Network (ISDN) Basic Rate Interface (BRI) to Network 1.
Both Router A and Router B need to spoof SPX keepalives. Router A is spoofing on Network 100 and Router B is spoofing on Network 200. The ISDN interface connects Router A to Router B and its remote clients.
Enable SPX spoofing using the ipx spx-spoof command. Note that route caching must be turned off before enabling this feature. Use the ipx spx-idle-time command to set the time in seconds that must elapse before spoofing of keepalive packets can occur.
Figure 6. SPX Spooling
To make sure that licensed copies of NetWare are not being improperly copied to other servers, the NetWare operating system has a built-in copy protection scheme. Each NetWare server transmits a packet (a unicast to all file servers) containing its unique serialization number at roughly 66-second intervals. When a server detects duplicate serialization identifiers, it broadcasts a copyright violation message to all users and the console log.
One solution to the problem of serialization packets keeping the link up is to filter them. This solution has some drawbacks because it could allow users to bypass Novell's licensing scheme. Although inelegant, filtering is the only solution to the NetWare serialization packet problem supported by the Cisco IOS software. It is done using the Cisco IOS software access-list command.
Novell NetWare 4 uses the concept of directory services in its operating system. Directory services enable NetWare 4 to create databases of information about the network environment. The NetWare Directory Services (NDS) provides a distributed management framework that allows global access to all network resources. NDS is based on the International Telecommunication Union Telecommunications Standardization Sector (ITU-T) X.500 standard. This standard defines a method for organizing information that is accessed transparently on a global basis, such as information services available on the Internet. NDS is based on a hierarchical, object- oriented architecture. This architecture allows objects to be organized in a multilevel structurethat Novell refers to as a Directory tree. The Directory tree is highly structured and is ordered by a Directory schema that defines Directory objects in which information is stored. Directory objects can be both actual and logical resources and are stored in Container objects. Continuing with the hierarchical structure, Container objects are further divided into groups that store related items in the Directory tree. Each type of object is assigned certain properties and values, making tracking and managing the actual information---which could be login names, e-mail addresses, server addresses, or other such information---a much easier task.
Directory objects are managed by management utilities and by the concept of Directory partitions. Directory partitions have hierarchical structures and allow a distinct unit of data in the Directory tree to store and replicate Directory information. A partition contains unique chunks of related data that cannot overlap or exist in other partitions. An object can exist in only one partition, but there can be an unlimited number of copies or replicas of a partition. The replicas can be stored on any NetWare 4 server on the network.
So what happens if changes are made to objects in the partitions, especially if there are numerous replicas of the partitions stored throughout the network? The answer is simple; the changes are distributed to all replicas. The difficult part is ensuring synchronicity. Setting up time synchronization is an important task in the NDS.
NDS monitors each server in its replica list periodically to determine if changes have occurred and timestamps each event with a unique code that identifies the event. It uses the timestamp to establish the correct order of events, set expiration dates, and record time values. Four time servers are established:
These time synchronization checks and the updates required by NDS can often generate excessive traffic and activate dial-on-demand connections. There are several possible solutions for excessive traffic of this type in a network. The solutions could require some reconfiguration of the network and use of Novell NetWare Loadable Module (NLM) files. The NLM files are available with the Novell MultiProtocol Router (MPR), version 3.0. Novell customers can also contact the local Novell sales office and request these NLMs from the Novell NDS Product Manager in Provo, Utah. Novell is planning to make these NLMs available on line sometime in the future. Check the Novell Web pages for further information.
To reduce the time synchronization packet traffic, users can reduce the TimeSync Polling Interval in the TIMESYNC.NLM. An alternative fix, however, is to change the network configuration so that fewer servers need to synchronize across the DDR line. In Figure 7, only Servers E and A exchange time synchronization packets, thereby optimizing traffic across the DDR link.
Following is a summary of the time synchronization process. The servers are running Novell NetWare 4.x.
Refer to Novell documentation for the procedures to install and configure the TIMESYNC.NLM and AUTOEXEC.NCF files.
Figure 7. Recommended Configuration to Reduce Time Sychronization Traffic
Replication and distribution of partitions are an important part of the synchronization scheme used by NDS. This scheme requires circulating the internal network addresses to all servers in the network. To reduce the traffic this scheme can cause, the user can modify information in the DSFILTER.NLM and PINGFILT.NLM files. DSFILTER.NLM sets time windows that control when NDS traffic is allowed on the DDR line. This file requires the internal address of each remote server that exists on each end of the DDR line. The PINGFILT.NLM file uses the addresses to determine which NDS services to filter.
Figure 8 builds on the recommended configuration for reducing time synchronization packets in the DDR network and illustrates how to reduce replica synchronization traffic. The PINGFILT.NLM program is run on Servers A, B, C, D, and E.
Following is a summary of the replica synchronization process:
The DSFILTER.NLM program is used to configure when (time and day of the week) NDS traffic is allowed on the DDR link.
The internal network numbers of Servers C, D, and E are included in the list of filter addresses of Servers A and B.
The internal network numbers of Servers A and B are included in the list of filter addressed for Servers C, D, and E.
A Novell application note explains how to load the DSFILTER.NLM and PINGFILT.NLM files and make the necessary changes.
Novell's new routing protocol, Network Link Services Protocol (NLSP), addresses the problems associated with IPX RIP and SAP routing in congested networks. Unfortunately, it does not operate efficiently over DDR links. NLSP sends hello packets every 20 seconds by default to maintain its adjacencies and preserve routes. These hello packets keep DDR links constantly active.
Similar behavior by the TCP/IP link state routing protocol, Open Shortest Path First (OSPF), has initiated a Request for Comment (RFC) to deal with the problem. NLSP is closely related to both the International Organization for Standardization (ISO) Intermediate System to the Intermediate System Intra-Domain Routing Exchange Protocol (IS-IS) and to the OSPF protocol. RFC 1793 entitled "Extending OSPF to Support Demand Circuits" offers solutions to allow efficient operation of the OSPF protocol over DDR circuits. These enhancements change the way that OSPF hellos and the refresh of OSPF routing information are propagated and stored when demand circuits are involved, allowing the DDR connections to be closed when not carrying application traffic.
Figure 8. Recommended Configuration to Reduce Replica Sychronization Traffic
Several router vendors have announced methods of dealing with NLSP over DDR circuits. Most often these solutions are simply identified as hello spoofing, a vast oversimplification of the actual process. However, since the NLSP standard is maintained by Novell, and no standard method of extending NLSP to DDR links has been published, all of these solutions are by definition proprietaryand not interoperable.
Cisco understands the importance of developing a standard method of extending NLSP to efficiently work over DDR circuits. When a standard is defined, and interoperability is assured, Cisco intends to implement the solution. Until that time, interoperability can only be achieved through the use of static routes. In Cisco-based networks, IPX RIP and snapshot routing can be used to permit dynamic routing.
Although it might be thought that subscribing to WAN services such as ISDN when using a chatty network operating system such as Novell's NetWare is prohibitively expensive, it does not have to be so. Cisco Systems assists its customers in designing and operating efficient networks by providing tools, information, and support. The network manager can use the information in this paper to recognize when excessive traffic in the NetWare network is switching on the DDR link unnecessarily and to determine the steps necessary to reduce the traffic.